home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 459 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.6 KB  |  139 lines
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: hickeyr@ibm.net (Rich Hickey)
  3. Newsgroups: comp.std.c++
  4. Subject: Proposal: Reconcile Inheritance and Inlining
  5. Date: 23 Feb 1996 15:55:20 GMT
  6. Organization: Sun Microsystems Inc., Mountain View, CA
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4gkas9$4o84@news-s01.ny.us.ibm.net>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Content-Type: text
  11. X-Nntp-Posting-Host: slip166-72-132-91.tx.us.ibm.net
  12. X-Newsreader: NeoLogic News for OS/2 [version: 4.2]
  13. Content-Length: 3830
  14. X-Lines: 115
  15. Originator: clamage@taumet
  16.  
  17. Proposal: Reconcile Inheritance and Inlining
  18. --------------------------------------------
  19. Rich Hickey
  20. rich@rcs-hq.mhs.compuserve.com
  21.  
  22. Rationale:
  23. ----------
  24.  
  25. C++ suppports a powerful and flexible mechanism for inheritance, and for 
  26. polymorphism via virtual functions.  It also supports the notion of 
  27. inlining, which when used correctly can provide for execution speed as 
  28. good as hand-written low-level code.  
  29.  
  30. Unfortunately, due largely to the way virtual functions are implemented 
  31. (and I am not suggesting there is a better way to implement them), while 
  32. virtual functions can be specified as inline, the vast majority of calls 
  33. to virtual functions, i.e.  those through pointers or references, cannot 
  34. be inlined.  
  35.  
  36. This has led developers to a distinct and rather arbitrary design 
  37. decision - hierarchy and polymorphism vs. speed when using concrete 
  38. classes, due largely to a mechanical language implementation artifact.  
  39.  
  40. In many cases where this decision is made, the hierarchical design takes 
  41. the form of a tree of 100% abstract classes on inner nodes, with 
  42. concrete classes occupying the leaf nodes.  In the non-hierarchical 
  43. design there are concrete classes with inline functions, and no virtual 
  44. functions.  In both cases the concrete classes represent the 
  45. 'end-of-the-line', and are not intended to be derived from.  
  46.  
  47. More often than not these days, the decision is made to abandon 
  48. hierarchy so as to ensure optimal performance when manipulating the 
  49. concrete classes.  Even those that treasure the performance possible 
  50. with such designs are dismayed by the ease-of-use and flexibility lost 
  51. in not being able to provide a hierarchy, particularly in building large 
  52. systems where polymorphism is key to providing loosely-coupled 
  53. architectures.
  54.  
  55. This prosposal sugggests a bridge that will support both hierarchy and 
  56. inlining (in the context given above).  
  57.  
  58. -----------------------------------------------------------------------
  59. I propose that the explicit keyword be allowed as a qualifier of a class 
  60. definition, such qualification taking the form of:
  61.  
  62. explicit class X{
  63.   //the definition of X
  64.   };
  65.  
  66. and that such qualification has the following meaning:
  67.  
  68. For any class X defined as explicit -
  69.  
  70. X cannot be derived from.
  71.  
  72. Any calls to member functions of X, even through pointers or references 
  73. to X, be called with the 'normal' function mechanism, i.e.  not the 
  74. virtual function mechanism, as if the call took the form of 
  75. x->X::function().  That is to say, all calls on X's are in the explicit 
  76. scope of X.  (Language lawyers please refine)
  77.  
  78. Note that the explicit need only appear at the single  point of 
  79. definition. This is not a type qualifier, and would _not_ appear 
  80. anywhere else, in declarations, argument lists etc.
  81.  
  82. Example:
  83.  
  84. class B{
  85. public:
  86.    virtual int foo()const=0;
  87.    //...
  88. };
  89.  
  90. explicit class D:public B{
  91. public:
  92.   int foo()const{return data;}
  93.   //...
  94. private:
  95.   int data;
  96. };
  97.  
  98. void fred(const D &d)
  99.    {
  100.    d.foo();  //as if d.D::foo(); - inlined
  101.    }
  102.  
  103. void ethel(const B &b)
  104.   {
  105.   b.foo();    //even if b is a D, virtual function call (as always)
  106.   }
  107.  
  108. While the ban on derivation may seem draconian, it is hardly less 
  109. extreme than saying - 'this design will have no hierarchy'. In any case 
  110. the choice lies with the developer.
  111.  
  112. ---------------------------------------------------------------
  113. It is my (non-compiler/language developer) contention that this 
  114. extension is trivial to specify and implement.
  115.  
  116. It cannot be otherwise accomplished in the language, i.e. it requires an extension.
  117.  
  118. It requires no changes to existing code.
  119.  
  120. Anyone not using it is unaffected by it.
  121.  
  122. It has no side-effects I have been able to think of.
  123.  
  124. It significantly enhances the language and the power and flexibility of 
  125. developers using the language by reconciling 2 fundamental C++ idioms.
  126.  
  127. Rich
  128.  
  129.  
  130.  
  131.  
  132.  
  133. [ To submit articles: Try just posting with your newsreader.
  134.               If that fails, use mailto:std-c++@ncar.ucar.edu
  135.   FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  136.   Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  137.   Comments? mailto:std-c++-request@ncar.ucar.edu
  138. ]
  139.